Open Access: how to make information consumable and geared towards stakeholders, answering their needs, vs. presenting information in a way I would like to.

There is a huge digital negotiation anticipating platforms in a public history project. It is public history because it is built taking into account the stakeholders. The line is grey between 'public history' and 'regular history' because of the potential each digital project has to be viewed by the public. But here, a public history digital project is one that accounts, expects, and must be built for a wider community usage rather than just a project that works on your machine. In other words, it means taking into account a range of accessibility issues rather than building solely around your platform.

Yet at some point, you cannot fully sacrifice a project to satisfy outdated or poorly browsers. There is some functionality in my website that may slow with poor bandwidth or poor functioning browsers like Internet Explorer of Opera. On the other hand - with a project involving open access and reproducibility - I cannot create a completely experimental design that is only supported by ultra-modern browsers with full support, run on a machine with high working memory, and a network with consistent speeds. I tried to account for these issues by configuring the website for all major browser standards, as well as offering this project to be downloaded as a desktop app. That way, aside from the initial download, I remove network issues running this project online. In a typical website, a server hosts all files which are called by the user only when needed. For instance, your computer does not preload all the pages of a website. Rather, when you click a link to go to the next page of the website, it sends a request to the server for that page. Now, this is not the absolute case - not only do scripting and stylistic elements preload on a web page, but newer, single page web applications preloads the pages of a website which increases a websites speed and efficiency (ex. see this SPA I created using AngularJS captialhistory.ca).

Throughout building this project, I struggled with the core principle that underlies my actions and creative powers: open access. The goal was to use digital projects as a kind of historiography of open access (where git commits, code commenting, etc. acts as a historiographical record). I would take the source code of a current digital project on Github, fork and modify the code to fit my needs. I started with DAEA but found Jack Dougherty's storymap more tailored to my needs (which in turn was forked on a Github project based on a different Mapbox project). Yet every project has its limitations. I had less control than I needed over my project with the storymap source code because it is currently controlled through javascript. I could have completely overhauled the project, designing it so that the map is primarily controlled through HTML elements with GeoJSON rather than javascript controlling HTML interpreted through GeoJSON (as in the original Mapbox code https://www.mapbox.com/mapbox.js/example/v1.0.0/scroll-driven-navigation/). There were other options to present an interactive story-driven map (http://tympanus.net/codrops/2015/12/16/animated-map-path-for-interactive-storytelling/). But with the principle of open access, the leaflet javascript library that serves as the engine for my scroll driven map is entirely open source - meaning anyone can build upon it, making it there own - has full documentation, is used widely across many disciplines, and, therefore, has a great support community that consistently designs and produces new features.

Finally, I am bound by the practical time limitations of this project. I also had to do the actual historical fieldwork and archival research; write the front end website text for the users; manage file names and directories, comment on and explain code (ie. future proofing my work); procure and organize photos and sounds; scan and georectify the historical maps; and finally write a reflection on my work. All of these variables meant that I ended up with the project currently online, even if it is not the final product I necessarily wanted. Therefore, in my experience on this and other digital projects, I offer this definition of public history work: **the practice of producing a collaborative project that anticipates the explicit and implicit negotiated needs of constantly shifting known and unknown stakeholders, within a seemingly infinite and simultaneous dance of recursive and discursive 'limitations' that you recognize as forever incomplete. Public History work is about as easy to navigate as that definition. Put simply public historians are marketers acting with post structuralist ideas of history. And wche must be honest about the stakeholders that 'drive' our work and build in the potential to expand that work. I did this by letting people tell their own stories, brushing both against and along the historical narrative, and making my work entirely open and reproducible. By showing the history of strikes and recognizing that there is a history before settlers in Pembroke, that sounds are not entirely the same to everyone, I hope to cause a positive level of discomfort. But, of course, this is a subtle art.

But there is one final issue that arose on this last point: people expect historians to tell them facts and stories about the past. Maybe this project will be viewed with an academic backdrop and thus not receive the same input or level of discussion as when I post archival photos to Pembroke. I hope I made this map accessible enough (with the map, historical maps, timeline, and sounds).